Fix map_query_sql benchmark duplicate key error #18427
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The build_keys() function was generating 1000 random keys from range 0..9999,
which could result in duplicate keys due to the birthday paradox. The map()
function requires unique keys, causing the benchmark to fail with:
'Execution("map key must be unique, duplicate key found: {key}")'
This fix ensures all generated keys are unique by:
- Using a HashSet to track seen keys
- Only adding keys to the result if they haven't been seen before
- Continuing to generate until exactly 1000 unique keys are produced
Fixes apache#18421
Contributor
|
LGTM. |
Jefffrey
reviewed
Nov 5, 2025
Contributor
Jefffrey
left a comment
Jefffrey
left a comment
There was a problem hiding this comment.
Looks like need to resolve some conflicts
| let mut keys = vec![]; | ||
| for _ in 0..1000 { | ||
| keys.push(rng.random_range(0..9999).to_string()); | ||
| let mut seen = HashSet::with_capacity(1000); |
Contributor
There was a problem hiding this comment.
We could also make keys a HashSet and just keep inserting into it until it reaches 1000 instead of having both keys and seen
Contributor
|
Took the liberty of pushing some commits to get this PR over the line |
Jefffrey
approved these changes
Nov 17, 2025
Contributor
|
Thanks @atheendre130505 for initiating this |
logan-keede
pushed a commit
to logan-keede/datafusion
that referenced
this pull request
Nov 23, 2025
Fix map_query_sql benchmark duplicate key error
Description
The build_keys() function was generating 1000 random keys from range
0..9999, which could result in duplicate keys due to the birthday
paradox. The map() function requires unique keys, causing the benchmark
to fail with: Execution("map key must be unique, duplicate key found:
{key}")
This fix ensures all generated keys are unique by:
Using a HashSet to track seen keys
Only adding keys to the result if they haven't been seen before
Continuing to generate until exactly 1000 unique keys are produced
Fixes apache#18421
Which issue does this PR close?
Closes apache#18421
Rationale for this change
The benchmark was non-deterministic: it could pass or fail depending on
random key generation. With 1000 keys from a range of 9999 values,
collisions are likely (~50% chance), making the benchmark unreliable.
This change ensures uniqueness so the benchmark consistently succeeds
and accurately measures map function performance.
What changes are included in this PR?
Added use std::collections::HashSet; import
Modified build_keys() to:
Track generated keys using a HashSet
Only add keys if they are unique
Continue generating until exactly 1000 unique keys are produced
File changed: datafusion/core/benches/map_query_sql.rs
Code changes:
Added HashSet import at the top of the file
Replaced simple loop with uniqueness-checking logic in build_keys()
function
Are these changes tested?
The fix was verified by:
Logic review: the HashSet approach guarantees uniqueness
Code review: changes follow Rust best practices
No linter errors
The benchmark itself serves as the test — running cargo bench -p
datafusion --bench map_query_sql should now complete without errors.
Before this fix, the benchmark would fail with duplicate key errors in a
significant portion of runs.
Are there any user-facing changes?
No user-facing changes. This is an internal benchmark fix that ensures
the map_query_sql benchmark runs reliably. It does not affect the public
API or any runtime behavior of DataFusion.
---------
Co-authored-by: Jefffrey <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix map_query_sql benchmark duplicate key error
Description
The build_keys() function was generating 1000 random keys from range 0..9999, which could result in duplicate keys due to the birthday paradox. The map() function requires unique keys, causing the benchmark to fail with: Execution("map key must be unique, duplicate key found: {key}")
This fix ensures all generated keys are unique by:
Using a HashSet to track seen keys
Only adding keys to the result if they haven't been seen before
Continuing to generate until exactly 1000 unique keys are produced
Fixes #18421
Which issue does this PR close?
Closes #18421
Rationale for this change
The benchmark was non-deterministic: it could pass or fail depending on random key generation. With 1000 keys from a range of 9999 values, collisions are likely (~50% chance), making the benchmark unreliable. This change ensures uniqueness so the benchmark consistently succeeds and accurately measures map function performance.
What changes are included in this PR?
Added use std::collections::HashSet; import
Modified build_keys() to:
Track generated keys using a HashSet
Only add keys if they are unique
Continue generating until exactly 1000 unique keys are produced
File changed: datafusion/core/benches/map_query_sql.rs
Code changes:
Added HashSet import at the top of the file
Replaced simple loop with uniqueness-checking logic in build_keys() function
Are these changes tested?
The fix was verified by:
Logic review: the HashSet approach guarantees uniqueness
Code review: changes follow Rust best practices
No linter errors
The benchmark itself serves as the test — running cargo bench -p datafusion --bench map_query_sql should now complete without errors. Before this fix, the benchmark would fail with duplicate key errors in a significant portion of runs.
Are there any user-facing changes?
No user-facing changes. This is an internal benchmark fix that ensures the map_query_sql benchmark runs reliably. It does not affect the public API or any runtime behavior of DataFusion.